Skip to content

X25519DiffieHellman agreement with byte-based public keys#128086

Open
vcsjones wants to merge 6 commits into
dotnet:mainfrom
vcsjones:x25519-agree-with-bytes
Open

X25519DiffieHellman agreement with byte-based public keys#128086
vcsjones wants to merge 6 commits into
dotnet:mainfrom
vcsjones:x25519-agree-with-bytes

Conversation

@vcsjones
Copy link
Copy Markdown
Member

Contributes to #128040.

This introduces a DeriveRawSecretAgreement that does key agreement with the other party's key as a sequence of bytes instead of forcing creating the instance of X25519DiffieHellman. This reduces allocations in the typical use case of X25519.

Copilot AI review requested due to automatic review settings May 12, 2026 16:52
@dotnet-policy-service
Copy link
Copy Markdown
Contributor

Tagging subscribers to this area: @bartonjs, @vcsjones, @dotnet/area-system-security
See info in area-owners.md if you want to be subscribed.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR extends X25519DiffieHellman with byte-based public-key key agreement APIs and wires them through the platform implementations (OpenSSL/Apple/Windows/CNG), adding native shim entrypoints where needed, plus expanded contract and functional test coverage.

Changes:

  • Add DeriveRawSecretAgreement(byte[] otherPartyPublicKey) and DeriveRawSecretAgreement(ReadOnlySpan<byte> otherPartyPublicKey, Span<byte> destination) along with a new abstract DeriveRawSecretAgreementCore(ReadOnlySpan<byte>, Span<byte>).
  • Implement the new core overload across OpenSSL/Apple/Windows/CNG implementations and add new native entrypoints for OpenSSL and Apple to derive directly from raw public-key bytes.
  • Add/extend tests validating argument checks, disposal behavior, symmetry, vectors, and zero-shared-secret behavior for the new overloads.
Show a summary per file
File Description
src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X25519DiffieHellman.cs Adds the new public overloads and new abstract core method plus length validation helper.
src/libraries/System.Security.Cryptography/ref/System.Security.Cryptography.cs Updates the public ref surface to include the new overloads and abstract core method.
src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X25519DiffieHellmanImplementation.OpenSsl.cs Implements the new core overload and switches fallback to the new raw-public-key interop.
src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X25519DiffieHellmanOpenSsl.OpenSsl.cs Same as above for the public OpenSSL-backed type.
src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X25519DiffieHellmanImplementation.Apple.cs Implements the new core overload and routes to the new Apple bytes-based interop.
src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X25519DiffieHellmanImplementation.Windows.cs Implements the new core overload and refactors shared Windows derivation path.
src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X25519DiffieHellmanCng.Windows.cs Implements the new core overload and factors shared public-key handling.
src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X25519DiffieHellmanCng.cs Declares the new protected override in the partial type.
src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X25519DiffieHellmanImplementation.NotSupported.cs Adds the new core overload stub for unsupported platforms.
src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X25519DiffieHellmanOpenSsl.NotSupported.cs Adds the new core overload stub (currently throws NotImplementedException).
src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/Cng.NotSupported.cs Adds the new core overload stub in the CNG PNSE implementation.
src/libraries/Common/src/Interop/Unix/System.Security.Cryptography.Native/Interop.EvpPkey.X25519.cs Adds interop for the new OpenSSL native entrypoint deriving from raw public-key bytes.
src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_x25519.h Declares CryptoNative_X25519DeriveSecretAgreementWithPublicKey.
src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_x25519.c Implements the new OpenSSL helper by importing the peer key and deriving.
src/native/libs/System.Security.Cryptography.Native/entrypoints.c Exposes the new OpenSSL entrypoint via the resolver table.
src/libraries/Common/src/Interop/OSX/System.Security.Cryptography.Native.Apple/Interop.X25519.cs Adds interop for the new Apple bytes-based derivation export.
src/native/libs/System.Security.Cryptography.Native.Apple/pal_swiftbindings.swift Implements AppleCryptoNative_X25519DeriveRawSecretAgreementWithBytes and shares logic via a helper.
src/native/libs/System.Security.Cryptography.Native.Apple/pal_swiftbindings.h Declares the new Apple export.
src/native/libs/System.Security.Cryptography.Native.Apple/entrypoints.c Exposes the new Apple export via the resolver table.
src/libraries/System.Security.Cryptography/tests/X25519DiffieHellmanContractTests.cs Adds contract tests for the new overloads and adds callback plumbing for the new core method.
src/libraries/System.Security.Cryptography/tests/X25519DiffieHellmanBaseTests.cs Adds functional tests covering new overloads (symmetry, vectors, public-key-only, zero-secret).

Copilot's findings

  • Files reviewed: 21/21 changed files
  • Comments generated: 3

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings May 12, 2026 17:29
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot's findings

  • Files reviewed: 21/21 changed files
  • Comments generated: 1

Comment on lines 102 to 104
}

}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
}
}
}
}

Nit: stray blank line


[LibraryImport(Libraries.AppleCryptoNative, EntryPoint = "AppleCryptoNative_X25519DeriveRawSecretAgreementWithBytes")]
[UnmanagedCallConv(CallConvs = [ typeof(CallConvSwift) ])]
private static partial int AppleCryptoNative_X25519DeriveRawSecretAgreementWithBytes(
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels a little strange that in Apple you called it WithBytes and in OSSL you called it WithPublicKey.

Doesn't really matter, but stood out as weird.

Interop.AppleCrypto.X25519DeriveRawSecretAgreement(_key, publicKey, destination);
Span<byte> publicKeyBuffer = stackalloc byte[PublicKeySizeInBytes];
otherParty.ExportPublicKey(publicKeyBuffer);
Interop.AppleCrypto.X25519DeriveRawSecretAgreementWithBytes(_key, publicKeyBuffer, destination);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I'd write it as export then call DeriveRawSecretAgreementCore, but the logic is simple, so 🤷

The JIT would probably eat the redundant call to ThrowIfPrivateNeeded.


otherParty.ExportPublicKey(publicKeyBytes);

using (SafeBCryptKeyHandle otherPartyKey = ImportPublicKey(publicKeyBytes, out _))
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is a little bigger than the Apple/OSSL one, so I'll restate the "why not just defer to the other one?"


AssertExtensions.SequenceEqual(secret1, secret2);
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably also good to show that key1.DeriveRawSecretAgreement(key2) matches, if that isn't done elsewhere. (That imported and from-bytes are the same)

It's indirectly shown by trying the KATs through both forms, I guess?

Comment on lines 272 to +285
() => key.DeriveRawSecretAgreement(peer, new byte[X25519DiffieHellman.SecretAgreementSizeInBytes]));
}

[ConditionalFact(nameof(IsNotStrictKeyValidatingPlatform))]
public void DeriveRawSecretAgreement_Bytes_ZeroSharedSecret_Throws()
{
// Wycheproof tcId 64: peer public key is a low-order point on Curve25519.
// This low-order point produces a shared secret that is all zeros.
byte[] privateKey = Convert.FromHexString("387355d995616090503aafad49da01fb3dc3eda962704eaee6b86f9e20c92579");
byte[] peerPublicKey = Convert.FromHexString("5f9c95bca3508c24b1d0b1559c83ef5b04445cc4581c8e86d8224eddd09f1157");

using X25519DiffieHellman key = ImportPrivateKey(privateKey);

Assert.ThrowsAny<CryptographicException>(() => key.DeriveRawSecretAgreement(peerPublicKey));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Personally, I'd put these just as one test, showing that the same imported key throws for both forms."

"This is a more 'pure' test, no question, because it shows that this exception isn't just the previous exception being rethrown.."

These together lead to the open question "do we have any tests that show that (this kind of) exceptions don't taint the object?"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants